【レポート】AWS で実現する攻めのシステムモニタリング #AWSSummit

こんにちは、岩城です。

2019年6月12日(水)〜2019年6月14日(金)の 3 日間にわたり、 千葉県の幕張メッセにて AWS Summit Tokyo 2019 が開催されています。

こちらで講演されたセッション「AWS で実現する攻めのシステムモニタリング」を聴講しましたのでレポートします。

概要

「あなたのシステム、ちゃんと監視できてますか？」 システムの安定運用のためには、適切な監視設計が欠かせません。AWS では CloudWatch や Systems Manager, Trusted Advisor など、クラウド上のシステム管理に役立つ様々なサービスを提供しています。本セッションではAWSサポートにこれまで蓄積された豊富なナレッジをもとに、Collect(収集)-Monitor(監視)-Act(行動)-Analyze(分析) のサイクルで実現する “攻め” のシステム監視のポイントをご紹介します。

スピーカー

• アマゾン ウェブ サービス ジャパン株式会社 技術支援本部 クラウドサポートエンジニア
  • 関山 宜孝

※敬称略

レポート

対象者

• AWSクラウド上のシステムの監視や運用を設計するエンジニア

アジェンダ

• "攻め"の監視設計のポイント
• 適応型モニタリングのコンセプト
• モニタリングデザインパターン

攻めの監視設計のポイント

• "攻め"の監視ではないもの
  • 全インスタンスでCPUやメモリといったリソース監視
  • オンプレの監視設計を転用
  • 監視ツールのテンプレをそのまま使用したら良いか
• "攻め"の監視
  • 本来の要求を高水準で満たし新たな価値を生み出す監視
• クラウドを利用し新規開発したり移行する際
  • 監視原点に立ち返り、クラウドを最大限活かし"攻め"の監視に変えるチャンス

そもそも何のために監視するの？

目的1:アプリケーションの正常性をチェックする

• アプリケーションの動作状態の正常性を測定する
  • SLA合意を定義し達成度を計測する
  • 個別のリソースではなくアプリレベルの状態を収集する必要がある
    • WEBシステムならば、応答時間や5XXエラー
    • バッチシステムならば、処理時間(目標完了時間の超過の有無)
• アプリを元の状態に回復する
  • アプリの正常/異常を定義する
  • 異常状態への状態変化を検知する
    • メトリクスのしきい値チェック
    • アプリからメッセージ送信
  • 異常状態から正常状態に復旧する方法を用意する
    • 自動復旧：マニュアル操作なし
    • 手動復旧：通知を受けてオペレータが操作
  • トラブルの原因を調査する
    • アプリリソースの動作状況を記録する
    • 動作状況を示すログやメトリクスが必要
    • 事象の因果関係を調査するために高いレベルのログやメトリクスが必要
    • トラブルに関係する記録を保全する
    • 調査対象になり得る期間を定義する
    • リソース削除前にメトリクスやログを回収する

ユーザー行動を分析する

• ユーザー行動を記録する
  • アクセスログ
  • 行動
  • クリックストリーム
• 将来の行動トレンド

キャパシティを分析する

• リソースに関する状況を記録する
• 個々のコンポーネントのリソースレベルの情報を記録する必要がある
• 記録したリソース状況から将来のキャパシティを予測する

目的と監視方法がマッチしないアンチパターン

よくある間違い

• WEBアプリの正常性チェックのためにApacheプロセスを監視
  • プロセス起動有無とアプリの動作が正常化は異なる
  • AWSアプリの清浄せチェックにはユーザリクエストをはっせいさせて応答を確認すべき
• 情報不足
  • オートスケールの結果インスタンスが消失してログも消失
    • トラブル調査に必要になる可能性のある情報は保全方法の事前検討が必要
  • リアルタイムシステムの調査用に5分間隔のメトリクス収集
    • 秒単位のリアルタイム性が必要なシステムの調査には秒単位の粒度での目と陸記録が必要
• 通知過多
  • ERRORを含むログが出力されたら全部メール通知
  • アプリにて検知した状態とそれに対して実行したいアクションは常に対応ように通知を厳選すべき
  • オオカミ少年になってしまう
  • ERRORに繋がらないのであればログを溜めておいて後で分析する

クラウドとオンプレの違い

• リソースをオンデマンドに追加削除できる
• リソースが一時的にしか存在しない
• マネージドサービスが提供されている
• クラウド特有の仕組みサービスが用意されている
• クラウドの特性を考慮して監視設計することが大切

適応型モニタリングのコンセプト

AWSにおける適応型モニタリング

• Collect(収集)-Monitor(監視)-Act(行動)-Analyze(分析)の4ステップを繰り返して監視設計をシステムに適応させ続けるプロセス
• 本来の要求を高水準で満たし新たな価値を生み出す

Collect(収集)

• システム監視にはまず現状の把握が大切
• 監視目的から収集対象、粒度、保存期間を決める
  • 目的ごとに収集するべき対象のメトリクスや粒度、保存すべき期間は異なる
• 収集対象、粒度、保存期間はコストとのトレードオフ
  • コストを考慮しつつ優先度の高いものから収集
  • コストを十分許容できる場合、できるだけ詳細かつ多量に保管することも可能
• メトリクスの収集
  • CloudWatch メトリクス
  • 標準メトリクス
    • EC2やRDSなどで標準で提供されるメトリクス
  • カスタムメトリクス
    • アプリレベルのメトリクスもAPI経由で登録可能
    • LambdaからWEBにHTTPリクエストを送信して外形監視も可能
  • エージェントの利用
    • インスタンスにエージェント導入することで、リソースメトリクスを収集可能
• ログの収集
  • CloudWatch Logs
    • 標準ログ
    • カスタムログ
    • エージェント経由でアプリログを取得
  • Kinesis Data Firehose
    • CloudWatch Logs上のログをS3やElasticsearchに転送
    • フォーマット変換も可能
  • Cloud Trail
  • VPCフローログ
  • S3/ELB/Cloud Frontのアクセスログ

Monitor(監視)

• 収集した状態を適切な方法で把握・確認する
• 目的に応じた監視
  • ダッシュボードに一元表示
  • リアルタイムアラートの通知
• 通知頻度は運用負荷とのトレードオフ
  • 収集可能な限り収集して振り返って削る
  • 対応が必要なものだけを厳選して通知する
• 通知方法と宛先の検討
  • 重要度/緊急度をもとに通知方法を宛先に設定する
  • 緊急対応の場合は電話、それ以外はメールなど
• 複数メトリクスのグラフやログを表示
  • CloudWatchコンソール
  • CloudWatchダッシュボード
• Elasticsearch+Kibana
  • Elasticsearchに蓄積したログを検索・可視化
  • CloudWatch LogsやKinesis Data Firehoseからデータ連携可能
• TrustedAdvisor
  • ユーザの利用状況を元にベストプラクティスからガイダンスを提供
  • コスト削減
  • パフォーマンス
  • セキュリティ
• 通知
  • CloudWatch Alarms
  • メトリクスの条件をに満たした場合、SNSやLambda利用して任意の通知可能

Act(行動)

• 収集・監視した状態をもとに適切なアクションを取る
• 目的に応じたアクション
• 状態とアクションの対応付け
• リソースの調整
  • Auto Scaling
  • CloudWatchメトリクスをもとにリソースのキャパシティを自動調整
• システムの回復：リソース
  • 高可用性サービス
  • 高可用性オプションを持つサービス
  • Auto Scaling
  • ELBと連携してヘルスチェックに失敗したインスタンスを自動的に置換
  • AutoRecovery
  • インスタンスの基盤が故障した場合に別の基盤にマイグレーションして復旧
• システムの回復：アプリ
  • Design for Failureの原則
  • システムの一部のコンポーネントが故障してもアプリは継続動作するように設計する
  • リトライと冪等性
    • 失敗しても繰り返し実行することで正常な状態を目指す
    • 何度実行しても同じ結果になること
  • ステートフルよりステートレス
    • インスタンスにステートを持たせるとAuto Scalingによる自動交換ができなくなる
  • 回復しやすいアプリケーション
• オートメーション
  • CloudWatch Events
  • リソース状態の変化やAPI実行をトリガーにLambdaやSSMを実行
  • SSMを使って任意のコマンドを実行したり、バックアップのような一般的なタスクを実行できる

Analyze(分析)

• 収集した状態を中長期的に分析する
• 目的に応じた分析
  • 検索
  • 可視化
  • ビジネスインテリジェンス
• 検索
  • CloudWatch Logs Insights
  • Elasticsearch
  • もっと柔軟な検索をしたい場合に利用
  • Athena
  • S3上のファイルにクエリを投げて検索したい場合に利用
• 可視化
  • CloudWatch Logs Insights
  • Elasticsearch+Kibana
  • より立地にカスタマイズしたい場合に利用
• ユースケース ログ分析
  • アプリケーション監視と原因分析
  • 多量のログが出力される中でどのようにコスト効率よくログ監視すべきか
  • あらゆるログをElasticsearchにストリーミング
  • 全チーム向けの中央管理ログサービスを構築することができた
• ビジネスインテリジェンス
  • QuickSight
  • 様々なデータに接続できるBIサービス
  • インタラクティブなダッシュボードを簡単に作成可能
• 予測したい場合
  • Amazon Forecastのプレビューを利用
  • メトリクスなどの時系列データを元に予測する

ここまでのまとめ

• 継続的な振り返りと監視設計の見直し
• 監視設計を一度作ってそのままにするのは危険
• 監視サイクルを継続的に振り返って見直し、アプリケーションに適応した監視設計を目指す

モニタリングデザインパターン

MDP1：アプリレベル監視パターン

• 一般的なWEB3層システムを想定
• Collect(分析)
  • 外形監視
  • CloudWatch Eventsで定期的にLambdaを実行
  • LambdaからHTTPリクエスト
  • ELBのアクセスログに出てくる応答時間の内訳を活用
• Monitoring(監視)
  • CloudWatchメトリクスをアラームでチェック
• Act(行動)
  • Auto Scaling
• Analyze(分析)
  • Athenaでユーザ行動を分析
  • QuickSightで将来のユーザ行動を予測

MDP2：モニタリングインテグレーションパターン

• オンプレとAWSを二重に監視することを想定
  • オンプレで利用しているサードパーティの監視ソフトサービスをインテグレーションしてCloudWatchから情報を転送

MDP3：ログ集約・分析プラットフォームパターン

• EC2ログ、VPCフローログ、Cloud Trail、S3/ELB/CloudFrontのアクセスログ
• CloudWatchLogsエージェントを使ってCloudWatchLogsに収集
• CloudWatchLogs→Kinesis Data Firehose→S3にログ出力可能
• 必要であればS3にあるログをGlueを使って変換・整形
• ログをクエリしたければAtheenaやQuickSightで確認

まとめ

• "攻め"の監視設計ポイント
  • 監視目的の振り返り
  • 目的にマッチした監視方法の選択
  • クラウドの特性を考慮した監視
• 適用型モニタリングのコンセプト
  • Collect(収集)-Monitor(監視)-Act(行動)-Analyze(分析)
  • 継続的な振り返りと監視設計の見直し
• モニタリングデザインパターン
  • アプリケーション監視
  • インテグレーション
  • 分析